Apparatus and method for monitoring and controlling laboratory information and/or instruments

ABSTRACT

A system and method for handling laboratory information includes a graphical user interface with a plurality of windows. A palette of icons is provided in a first one of the windows, each icon representing a predetermined task to be executed by a processor in communication with the graphical user interface. The processor is also in communication with a database containing static laboratory data (such as the type of sample to be analysed) as well as dynamic laboratory data (such as the name of the specific sample to be tested and the results of that test). A user can select icons from the first window and “drag and drop” them into a second window. A sequence of tasks may thus be built up, in the form of a tree structure, and when run the processor executes the sequence of tasks in turn by reference to the static and dynamic laboratory data.

This application is a 35 U.S.C. §371 filing of International PatentApplication No. PCT/GB99/01569, filed May 17, 1999. This applicationclaims priority benefit of Great Britain Patent Application No.9810574.5, filed May 18, 1998.

FIELD OF THE INVENTION

This invention relates to the field of monitoring and controllinglaboratory information and/or laboratory instruments.

BACKGROUND TO THE INVENTION

The word laboratory may be taken to encompass many different types ofestablishment, from a single room containing one or two scientificinstruments to a building housing hundreds of scientists and pieces ofequipment; from a place of academic research to the process control roomof a brewery, food manufacturing plant, oil refinery, chemical orpharmaceutical facility etc. What most laboratories have in common istheir function of performing scientific tests or experiments and theirproduct, laboratory information. In a modern laboratory, there may behundreds of samples, in respect of each of which hundreds of items ofdata must be known such as the sample's origin, its amount, its likelyconstituents, the chain of custody of the sample, any tests it hasundergone (and their results) etc. There will also be informationregarding any tests that the sample should undergo in the future andinstructions as to the carrying out of these tests, amongst many othertypes of information and instructions.

The task of handling and managing these data and instructions for even asmall laboratory can be vast, and for this purpose different types ofLaboratory Information Management System (LIMS) have been proposed. LIMSare software-based systems using databases to store, retrieve,manipulate and report laboratory data, to provide information about workbeing and to be undertaken and/or to control laboratory instruments. TheLIMS may provide spreadsheet, word processor, statistical and qualitycontrol functions in addition to other functions which may be specificto certain types of laboratory for example a commercial researchlaboratory may require an automatic billing function. The LIMS may alsodirectly control a number of scientific instruments. Since the needs ofeach laboratory are different, a typical LIMS package may not fulfil alla laboratory's requirements “out of the box”, but will require somecustomisation, either by the vendor or by the customer. Suchcustomisation may require many weeks of expensive coding, with orwithout the aid of regulated business models, in order that the LIMSsystem can operate according to a particular laboratory's exactrequirements. Should these requirements change at a future date, forexample with the introduction of new statutory requirements, furtherexpensive coding will be necessary. The amount of effort required tocustomise the base software can often be the major financial and timecost of a LIMS installation. The flow of events happening to a sample ina typical prior art LIMS is shown in FIG. 1. Before running any samples,the system is configured by defining various static data tables andentering data therein. This information will typically be about thelaboratory environment, the types of analyses which can be performed,the test schedules and the types of samples to be analyzed. In FIG. 1these steps are shown as boxes 1, 2, 3 and 4 respectively. Once thisdata is entered, samples may be run. A sample is logged in as shown inbox 5 and a worksheet is generated (box 6) giving a list of tests to becarried out on the sample. This worksheet may for example be printed outon paper as a series of instructions for a human operator, as a bar codeto be read by a bar code reader or automatically sent to an instrumentor series of instruments for automatic handling of a sample. The resultsof these tests are then entered into the system (again either manuallyor automatically)—this is shown as box 7. The results may then beoutputted in report form (box 8), and/or checked against nominal valuesto check the quality of the product from which the sample was drawn (box9). Once the results have been authorised (box 10) the data can bearchived.

In a typical LIMS the sequence of work is broadly fixed, although eachindividual step may be modified by the user. Changing the sequence ofevents, or adding further logical branches (e.g. IF . . . THEN . . .ELSE nodes) to the sequence usually requires the development of customcode, generally in the programming language of the LIMS, which may be aproprietary language unique to that LIMS. Such customisation is not onlycomplex and expensive but it can lead to problems for the customer interms of upgrading and validating their LIMS. For example, the businessprocess of a particular laboratory may require that each time a samplearrives from a particular client, a receipt should be generated and sentto that client. In a traditional LIMS, the services of an experiencedanalyst would be required to design and code a custom mechanism for thisscenario.

SUMMARY OF THE INVENTION

The object of the present invention is to provide a LIMS which obviatesthe need for such customisation. In particular, the object of thepresent invention is to provide a LIMS which allows the user readily togenerate and modify the sequence of event to be undergone by a sample orsamples. Another object of the present invention is to provide a LIMSwhich is easy to use and modify. A further object of the invention is toprovide means for monitoring and/or controlling laboratory informationand/or instrumentation which is easily configured and used by the user.These and other objects are realized by the invention as describedbelow.

According to a first aspect of the present invention, there is provideda laboratory control system, which has an electronic storage device forstoring static and dynamic laboratory data. The system also has a systemdata input/output which sends instructions to the laboratory andreceives dynamic laboratory data back. A GUI and a user input allow asequence of tasks to be defined which a processor executes in turn,using the static and the dynamic data, the latter of which is obtainedfrom the laboratory.

There are a number of advantages to the system of the invention over theprior art. Firstly, the use of graphical symbols or ‘objects’ allowsstraightforward set up of a complex sequence of tasks (hereafterreferred to as a ‘workflow’) without the need for a skilled programmer.Secondly, the overall amount of code that needs to be written isdramatically reduced with the present invention. Each symbol or ‘object’requires a finite amount of code to be written to allow the taskfunction to be fully specified, as well as to allow connection orlinkage to other tasks.

For example, to define a suitable number of different sequences orworkflows to address most eventualities in a laboratory informationmanagement system may require several tens of different symbols in thearray of symbols, requiring several tens of thousands of lines of codes.However, to write separate bespoke programs to address the manydifferent test procedures in a large laboratory (as frequently occurredin the prior art) may require several million lines of code.

The term ‘static laboratory data’ will be understood by those skilled inthe art to refer to the body of information held by the laboratory, in adatabase for example, and which relates to procedures which tend not tochange with time. By way of example only, static laboratory data mayinclude the types of samples to be analysed and the types of analyses tobe performed.

Likewise, the term ‘dynamic laboratory data’ will be understood by theskilled reader to refer to the body of information held by thelaboratory, again in a database for example, and which usually relatesto procedures specific to each particular experiment. For example,dynamic laboratory data may include the identification of a specificsample to be analysed, or the results of such analysis.

The invention also extends to a method of controlling data relating to,and obtained from, a laboratory. A computer program product embodied ona computer readable medium is also provided. Other features andadvantages will become apparent from a review of the following detaileddescription.

BRIEF DESCRIPTION OF THE DRAWINGS

An example of the invention will now be described in greater detail withreference to the accompanying drawings, in which:

FIG. 1 shows the flow of events in a typical prior art LIMS;

FIG. 2 shows examples of typical graphical symbols available to theuser;

FIG. 3 shows an example of how the display would appear in a particularaspect of the current invention;

FIG. 4 shows an example of the use of a Choice node;

FIG. 5 shows an example of the use of a Selection node;

FIG. 6 shows an example of a User Defined Event; and

FIG. 7 shows an example of the use of a subtree.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The operation of the invention relies on the concept of the workflow. Aworkflow in this context is a model of the laboratory process whichdefines the events be carried out on a sample or samples. The workflowmay include the steps of defining a sample and/or sample group,splitting off and defining aliquots of samples, specifying decisions tobe taken, tests to be applied and reports to be printed. The user canbuild a macroscopic workflow using graphical tools which correspond toworkflow nodes. In this way, often complex laboratory processes can bemodelled using a structured task list made up of a series of workflownodes selected by the user. The workflow can be structured toincorporate specific event nodes which allow status changes or reportprocessing, for example, to be triggered as a response to the outcome ofa particular test. In summary, a workflow defines the business rules forevents to be carried out on a sample. As the structure of a workflow ishierarchical, it is necessary to define workflows for results, tests,aliquots and samples before a sample workflow can be used for samplelogin. Details about particular steps in the workflow may be specifiedin associated templates, which may be pre-defined or defined by the userhimself.

A workflow can therefore be used by the user to model internal businesspractices, obviating the need for custom coding. To show an example ofone realisation of the invention, see FIG. 3 (the symbols used beingdetailed in FIG. 2), which shows how the screen would look when the userhas set up the system to handle a sample with its corresponding aliquot,complete with a single test and a set of results. The report beneath theevent node will run when the sample completes. Each symbol selected bythe user corresponds to a type of workflow node, as shown in FIG. 2.Each type of workflow node has a series of corresponding workflow tableswhich define the properties of each node. There may be many predefinednode types, some examples of which are shown in FIG. 2. As discussed,the workflow is a hierarchical structure, and the relevant table willdefine which node types may appear beneath the current node type. As anexample, it is valid for ALIQUOT nodes to appear beneath SAMPLE nodes,however the converse is not true. The data within this table is queriedwithin the workflow screen, when a user clicks on a node in the tree, sothat the user will not be allowed to position a node in a positiondisallowed in the table.

Certain workflow nodes may support events, for example “Completed” or“Schedule Item”. All events which may be associated with each node typemay be stored in a table associated with each node. Events may bepre-defined or user-defined—for example if the user's business processrequires an aliquot to be archived and a certain type of report to beprinted each time the sample fails a particular quality control test,the user may define this as an event. A user event can be triggered bysome part of the workflow or can be run manually by the user.

When the workflow is processed, the system reads the relevant table,instantiates objects internally, and then processes those objects. Foreach workflow node processed, the system looks up the relevant table,and creates an object of the type specified within it. In the case of asample node, for example, this forces a new sample to be logged into thesystem. The sample workflow node has a link to the sample template to beused at login, so the user is presented with the fields on that templatewithin the login screen. The sample record maintains a link back to theworkflow node used to generate it. When the sample status changes, adatabase trigger on the server is run, and that looks up the associatedworkflow nodes. A search is then made for any event nodes directly belowthe sample node in the workflow, and if found, a further check is thenmade on the nodes in the workflow to see if the event corresponds tothat occurring within the database. If the event matches one within theworkflow, an entry is then made on the background queue, which containsenough information for a background process to perform the subsequentnodes within the workflow. A workflow can automate the complex processeswithin a laboratory through the use of decisions. The business processmay state that every time a sample arrives from a particular client, ane-mail receipt should be generated and sent to that client. In atraditional LIMS, the services of an experienced analyst would berequired to design and code a custom mechanism for this scenario.Decisions of this nature are common, and with the current invention aresupported by the system “out of the box”. Two types of decisions aresupported—choices and selections. A choice permits the selection of oneof two alternatives, whereas a selection permits a choice between morethan two possible outcomes. FIGS. 4 and 5 show examples of the use ofthese nodes respectively. In the example shown in FIG. 4, the TestBARB_EL will only be assigned if the amount in the aliquot issufficient, otherwise the HPLC_B test will be assigned. The selectionnode extends the If—Then—Else processing capability of the choicenode—it permits multiple comparisons to be made, with a correspondinglist of multiple outcomes. The example shown in FIG. 5 performs anaction based on the conclusion of the aliquot. FIG. 6 shows an exampleof the display as seen by the user. Different windows may be selectedusing the tabs at the top of the screen. The user may select symbolsfrom the drop-down lists at the right hand side of the screen and placethem in the relevant position in the workflow in the left-hand window.Depending on the symbol selected (each symbol corresponding to a type ofworkflow node) a dialogue box may appear requesting further informationfrom the user, or a selection screen permitting the user to selectbetween options, as appropriate. Using the workflow model, decisions maybe nested to any depth, and are extremely powerful as the data used forthe decision may be retrieved from any dynamic node up the tree. Somedatabase fields only occur on the aliquot, such as the amount ofsubstance available within the aliquot. It is therefore possible to makedecisions on splitting aliquots, such as “If I have more than 100 ml,split into two test tubes and send one to MicroBiology and store theother in a freezer. If less, omit the split and send the vial directlyto MicroBiology”.

Workflows may be combined, building a large and possibly very complexset of decisions and data definitions from predefined simpler workflows.A Subtree node is used to link one workflow to another. FIG. 7 shows anexample, in which the workflow links to predefined aliquot and testworkflows. Saving workflows in this manner permits complex workflows tobe generated from reusable objects. The shortcut indicator (see FIG. 2)denotes a subtree. Aliquots are commonly split in the laboratory, sothat vials of the same sample can be tested individually by differentchemists. A Split node can be used within the workflow to automaticallygenerate these subsequent aliquots, and the system maintains a linkbetween any aliquot and its children, so that a hierarchy of aliquotscan be generated. To support extensions to the system, a User Definednode is included, which when run calls user-supplied code. The usercreates an object and the appropriate code is called by the system whenthe user object is encountered within the workflow. The User Choice nodeis similar to the User Defined node, but permits the user to supply codethat can evaluate the choice. Again the appropriate (user-supplied) codewill be called.

A Message Box node is used to display a message to the user, and wouldcommonly be incorporated into a user event workflow. The text definedwithin the workflow is presented in the form of a dialogue box.Information may also be provided on various factors such as clientfactors, container factors, product factors and instrument factors.Factors are used to supply arguments to calculations, and look upnumeric values stored in associated database tables. For instance,different clients may be charged according to different fee scales, thisinformation being stored in a table as appropriate. Using workflownodes, a user can select between various symbols, such as those shown inFIG. 2, to build up a workflow which is then actuated by the system.Instrumentation may be directly controlled by the workflow so that testsare performed automatically, or instructions may be made available cohuman operators to perform tests. Many other types of workflow node maybe defined and made available as appropriate.

The manner in which the workflow nodes actually link to the databases,for example, will be familiar to those skilled in the art and will notbe described in detail.

Furthermore, the nature of the database itself is no_critical to theoperation of the invention in its various embodiments. By way ofexample, the Oracle ™ database system may be employed to store staticand dynamic laboratory information. However, the static and dynamic datacould equally be stored in Extensible Mark-up Language (XML). Many othersystems, such as SQL/DS, may be equally suitable depending upon thespecific tasks to be carried out.

What is claimed is:
 1. A laboratory control system, comprising: anelectronic storage device, arranged to store an array of staticlaboratory data and an array of dynamic laboratory data; a system datainput/output for sending instructions to the laboratory, to generatedynamic laboratory data therefrom, and to receive dynamic laboratorydata generated by the laboratory; a graphical user interface providingan array of symbols each of which represents a task to be performed; auser input arranged to permit a user to define a sequence of tasks bylinking at least two of the array of symbols upon the graphical userinterface; and a processor arranged to control the system, the processorbeing configured to execute, in turn, the associated task represented bythe corresponding symbol selected by a user from amongst the array ofsymbols upon the graphical user interface by using data selected from atleast some of the array of static laboratory data or at least some ofthe array of dynamic laboratory data derived from the laboratory.
 2. Thesystem of claim 1, in which the electronic storage device is arranged tostore static laboratory data at least regarding the types of samples tobe analysed and the types of tests to be performed.
 3. The system ofclaim 1, in which the electronic storage device is arranged to storedynamic laboratory data at least regarding the identity of specificsamples to be analysed and the results of analyses carried out thereon.4. The system of claim 1, in which at least some of the array of symbolsrepresent a single associated task to be executed by the processor. 5.The system of claim 1, in which at least some of the array of symbolsrepresent a multiplicity of associated tasks to be executed by theprocessor.
 6. The system of claim 1, in which at least one of the arrayof symbols represents an associated task to be executed by a deviceexternal to the system, the processor executing the associated task whenselected by a user by using data obtained from the said device externalto the system.
 7. The system of claim 1, in which at least some of thearray of symbols represent fixed, predefined tasks to be performed. 8.The system of claim 1, in which at least one of the array of symbolsrepresents a task to be performed which task may be defined by a user.9. The system claim 1, in which the graphical user interface is arrangedto present the array of symbols in a first window, individual ones ofthe array of symbols being selectable for entry into a second window,the selected symbols being linkable within that second window.
 10. Thesystem of claim 9, in which the selected symbols within the said secondwindow are linkable in a hierarchical tree structure such that a firstselected symbol located at the root of the said tree structure and asecond selected symbol located upon a branch of that tree structurecauses the processor to execute a first associated task represented bythe first selected symbol before execution of a second associated taskrepresented by the second selected symbol.
 11. The system of claim 10,in which the electronic storage device is further arranged to store aset of rules defining one or more sequences of tasks which aredisallowed, the graphical user interface being in communication with theelectronic storage device via the processor such that a user isprevented from linking symbols upon the graphical user interface so asto define a sequence of tasks which is defined by the set of rules to bedisallowed.
 12. A method of controlling data relating to, and obtainedfrom, a laboratory comprising: (a) storing an array of static laboratorydata; (b) receiving and storing an array of dynamic laboratory data atleast some of which is updateable data generated by the laboratory; (c)providing an array of symbols upon a graphical user interface, eachsymbol representing a task to be performed; (d) defining a sequence oftasks by selecting and linking at least two symbols from amongst thearray of symbols upon the graphical user interface; and (e) executing,in turn, the associated task represented by the corresponding symbolthus selected, by using data selected from at least some of the array ofstatic laboratory data or at least some of the array of dynamiclaboratory data received from the laborory.
 13. The method of claim 12,in which the step (a) of storing an array of static laboratory data andan array of dynamic laboratory data includes the step of storing staticlaboratory data at least regarding the types of samples to be analysedand the types of tests to be performed.
 14. The method of claim 12, inwhich the step (a) of storing an array of static laboratory data and anarray of dynamic laboratory data includes the step of storing dynamiclaboratory data at least regarding the identity of specific samples tobe analysed and the results of analyses carried out thereon.
 15. Themethod of claim 12, in which the static laboratory data are stored priorto the step (d) of executing the associated task.
 16. The method ofclaim 12, in which the dynamic laboratory data are stored during thestep (d) of executing the associated task in response to a promptdisplayed by the graphical user interface.
 17. The method of claim 12,in which at least some of the array of symbols represent a singleassociated task to be executed.
 18. The method of claim 12, in which atleast some of the array of symbols represent a multiplicity ofassociated tasks to be executed.
 19. The method of claim 12, in which atleast some of the array of symbols represent fixed, predefined tasks tobe performed.
 20. The method of claim 12, in which at least one of thearray of symbols represents a task to be performed which task may bedefined by a user.
 21. The method of claim 12, further comprising:presenting the array of symbols in a first window upon the graphicaluser interface; selecting individual ones of the array of symbols forentry into a second window upon the graphical user interface; andlinking the selected symbols within that second window.
 22. The methodof claim 21, further comprising: linking the selected symbols withinthat second window in a hierarchical tree structure, and executing afirst associated task represented by a first selected symbol located atthe root of the said tree structure before executing a second associatedtask represented by a second-selected symbol located upon a branch ofthat tree structure.
 23. The method of claim 22, further comprising:storing a set of rules defining one or more sequences of tasks which aredisallowed; and preventing linkage of symbols upon the graphical userinterface when such linkage would result in a sequence of tasks which isdefined by the set of rules to be disallowed.
 24. A computer programproduct stored on a computer readable medium, the product being adaptedfor control of a computer comprising electronic storage means forstoring an array of static laboratory data and an array of dynamiclaboratory data, a graphical user interface providing an array ofsymbols each of which represents a task to be performed, and a processorin communication with the electronic storage means and the graphicaluser interface, the product comprising: computer readable program meansfor causing the processor to execute an associated task represented bythe corresponding symbol selected by a user of the computer from amongstthe array of symbols upon the graphical user interface; computerreadable program means for causing the processor to carry out the saidexecution by using data selected from at least some of the array ofstatic laboratory data and/or at least some of the array of dynamiclaboratory data; and computer readable program means for linking atleast two of the array of symbols upon the graphical user interface suchthat the processor is caused to execute each task represented by anindividual one of the array of symbols selected by the said user fromamongst the array of symbols in turn.
 25. The method of claim 11, inwhich at least one of the tasks defined within the said sequence causesinstructions to be sent to the laboratory which in turn result in thegeneration of the said updateable dynamic laboratory data.